Games of Daze

home *** CD-ROM | disk | FTP | other *** search

/ Games of Daze / Infomagic - Games of Daze (Summer 1995) (Disc 1 of 2).iso / x2ftp / msdos / pmode / code32 / code.doc < prev next >

Wrap

Text File | 1993-01-08 | 13KB | 277 lines

Intro crap: ----------- Hello coder... This is Tran typing... What have you got here??? Well, the ASM files that were so conveniently included with this doc, are most of the stuff you will need to begin coding in full protected mode of the 386+... Included are file routines, getting command line argumets, a low level keyboard handler, of course the protected mode header, and a little utility - CBTMEM - that you use on your EXEs to give them the ability to reboot any system infested with evil memory managers and the like so that your superior protected mode program may run undaunted by their lameness... I coded all this stuff for my own personal use, but give this now to you so that you may enjoy the total coding freedom of flat memory, totally under your control... The hardest thing of course, was the header itself - START32. There is almost no info out there on the mundane little things that you need to do to set the system up for protected mode ... Like enabling the A20, or reprogramming the IRQ handlers... Even now, the info I have is incomplete. But it is good enough to run on almost all systems. Protected mode: --------------- I find it sad that protected mode should be limited to technical things like "QEMM" or "Windows"... Anyone with a 386+ and good old regular DOS can take advantage of all that pmode has to offer... And thats what this code will help you to do... With this code, you can write full 32bit pmode crap, with nothing like the 64k, 640k, or 1M barriers to hinder you. If you don't code in assembler however, go no further, because this code will do you no good unless you are fluent in (and of course you have love of) assembly... And if you have never used the 386 instruction set before, then youre in for a treat. I suggest however that you get yourself a good book on the 386, because this doc can't explain everything for you... Files included: --------------- START32.ASM - Header code for getting in and out of, and handling protected mode. START32.INC - All extrns and macros you need to access various features of START32 from your module. START32.DOC - Old doc on technicalities of START32. FILE32.ASM - Library of some file functions. FILE32.INC - All extrns for FILE32. ARGC32.ASM - Three functions for getting command line parameters. ARGC32.INC - All extrns thereof (or whateverin, or howevercrap, or something). KB32.ASM - Low level keyboard driver. KB32.INC - Extrns, and one solitary 1 instruction macro. H.ASM - Blank generic header file thing. EXAMPLE?.ASM - Bunch of example programs. *.RT - Misc routines you can use. CBTMEM.EXE - Turns your EXEs into self-rebooting-then-running-again thingys so that people dont have to mess with their configs themselves. and various other little annoying pieces of propaganda for any and all boardz this file has been through. (Except of course for our own propaganda, which is OK). Ok, now what?: -------------- First thing's zeroth... Read START32.DOC, its a doc from the old released START32, with minor changes for time. If you are interested here are the annoying little bugs that were in that old release: ) The A20 enabling was far from perfect. ) There was no permission bitmap in the TSS for ports above 400h. ) A really really really stupid typo in the _getmem function. ) Problems with EXEs over 64K ) I forget what else... Now that you read that: ----------------------- I suggest you boot into a clean configuration (no memory managers or crap), then compile EXAMPLE0 and START32. Compile with multiple passes and case sensitivity on symbols (I'm assuming youre using TASM and TLINK). Then link and run the program you just created, if only to make sure it runs on your system. I don't know how much experience you've had with TASM or TLINK, so just in case you don't know, heres how you would do this: TASM /ML /M2 /Q START32 TASM /ML /M2 /Q EXAMPLE0 TLINK /3 /X START32 EXAMPLE0, EXAMPLE0 I'm assuming it ran: -------------------- And if it didn't... It's not my fault... Cuz it runs here... Anyways... now: --------------- To use the libraries, you would compile them, and link them in with your module and START32. You would also include the .INC files of the libraries you will be using in your module to make its functions and data areas available to your program. ------------------------------------------------------------------------------ FILE32: ------- This is a basic library of some file functions. They are: _openfile - I think this is self-explanatory. _readfile - ditto. _writefile - gee... what could this possibly be??? _createfile - I don't know... _deletefile - summons the devil... _findfile - ok, this one is the same as DOS int 21h functions 4eh, and 4fh (AL specifies which one upon entry). _lseekfile - same as int 21h function 42h. _filesize - returns the size of and opened file. _filecopy - copies ECX bytes from one open file to another. _closefile - guess... To get a slightly better understanding of these functions, check out FILE32 itself, and check out some of the example programs that use FILE32. Most of the functions will work immediately, without any setting up of anything by your program. However ... If you wish to read to a memory address physically above 1M, or write from there, you will have to set up an intermediate file buffer somewhere below 1M for FILE32 to use (Remember, plain DOS can't talk to memory above 1M)... Also, '_filecopy' always requires this buffer. But this is no problem, setting up this buffer is easy. There are two variables that specify the location and size of this buffer. '_filebufloc' is a pointer to the buffer area somewhere in low memory, your program must initialize this pointer, but you may modify it to point to a default area within your code. But why would you possibly want to do this? '_filebuflen' is the length of this buffer. 4000h bytes by default, but you may change it at compile time and run time. One thing to note. At the top of FILE32, there are several lines commented out. If you wish to use a function other than '_closefile', you must uncomment that file's token string in FILE32 before compiling it. This is merely because I don't like to waste code space, and include only what has to be included. If you don't want to bother, simply uncomment all these lines, and leave it like that, and all these functions be available without you having to edit FILE32 every time you want to use it. ------------------------------------------------------------------------------ ARGC32: ------- This lets you check command line argumets and switches. There are three functions. _cchekswitch - Checks for the presence of character AL preceeded by either a '-' or a '/' on the command line. This function is case sensitive, '_cchekswitchnc' is the same function, except that it is NOT case sensitive. _cchekstr - Gets a string from the command line. AL specifies which string, 0 is the first, 1 is the second, etc... _ccheksstr - check for the presence of a string IMMEDIATELY following a switch (such as '-ftest.doc'). This function is case sensitive on the switch. This little library also has token strings at the top for specifying wether to compile the functions or not. ------------------------------------------------------------------------------ KB32: ----- This is my low level keyboard interface thing. It replaces the BIOS int 16h keyboard handler (You can use the BIOS if you prefer... but WHY???). This thing ignores the CTRL-ALT-DEL sequence, and any other annoying little keypresses that the BIOS uses... But the best thing is, it allows you to specify your own handler for raw keyboard input. KB32 will handle talking to the keyboard controller, and can pass the value it reads on to your own routine. '_kbhand' is a pointer to the routine which will recieve the keyboard data. It points to a function in KB32 by default. That function processes the key code, and allows you access to the data like the BIOS. With the macro '@kbhit' you can check to see if a key was hit, and the function '_getch' returns the most recent keystroke (There is no keyboard buffering, (why bother)). One advantage of this handler over the BIOS, is that it returns the shift states along with the keypress. AL is the key pressed, and AH is the shift state returned (check out KB32.INC for bit assignments). The character recieved which is returned in AL, is not case adjusted. That is, if SHIFT is being held down, and you hit 'a', lower case 'a' will be returned, and not 'A'. If you do replace the default handler pointed to by '_kbhand' (You can do that at run time or compile time). Your must observe these rules in your handler: ) Your handler is being called out of an IRQ handler. ) DS and ES are set to their appropriate values, but FS and GS are not. ) AL contains the raw keyboard code. ) You may destroy EAX,EBX,ECX,EDX,ESI,EDI,EBP,DS,ES,FS, and GS. Before using the keyboard handler, you must initialize it with the function '_init_kb'. And before your program quits to DOS, you must call '_reset_kb'. If you set your own handler through '_kbhand', and you want to restore the default KB32 handler, use the function '_reset_hand'. ------------------------------------------------------------------------------ *.RT: ----- There are a bunch of filez with the extention '.RT'... These are just misc routines you can include in your module to do little things. If ya want to know what they do load 'em up and check 'em out... Some of the example programs put them to some use. ------------------------------------------------------------------------------ CBTMEM: ------- As a consequence of being a full-fledged protected mode program, the EXEs you create cannot run under any other memory managers that run the system in protected mode. Thus was born CBTMEM. You use this program on your .EXE files. CBTMEM puts a special header into them. This header detects if the system is running under the control of some other protected mode program. If the system is under the control of a memory manager, or something more evil, the user will be asked if he/she/it wants to try a clean boot. If they select yes, AUTOEXEC.BAT and CONFIG.SYS will be backed up on the root directory of the boot drive, and replaced with something k00ler. Then the system will reboot. The FIRST thing that is done after the reboot, is that the AUTOEXEC.BAT and CONFIG.SYS are restored ... Thus minimizing the possibility of any unnice things happening. Then the system will switch to the drive and directory of the program that was run, and it will be ran again. The command line arguments are not preserved however. After the program terminates, the user will be asked if he/she/it wants to reboot back into their original configuration. There are three things you put on the command line of CBTMEM. 1) The EXE you want to make self-booting (with the .EXE extention). 2) The minimum amount of low memory needed to run the EXE. 3) The minimum amount of extended memory needed. The low memory is there for this reason: Whenever people run things, their system is usually full of useless crap which just hogs memory, and if they dont have enough memory to run a program, they usually have to reboot anyway. You can have your EXE reboot for them if they don't have enough memory. If you don't want to reboot for that reason, simply set this number to 0. If you do want this 'feature', put the amount of free memory your program needs (minus its own code) in paragraphs in hex. The extended memory is the minimum amount of extended memory your program needs. If not enough extended memory is found, the program is not run. The means of checking is int 15h function 88h, which means that if you have any disk-caches or anything that is using that memory for something, it will not be corrupted. If you specified an amount higher than 0k, and an XMS driver is detected, the person will be given the choice to reboot. This number is also in hex, but is in K, not paragraphs like the low memory value. ------------------------------------------------------------------------------ Well, thats that: ----------------- Hope you like 32bit protected mode... And I hope there aren't too many typos in this doc... L8r... Tran...